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(54) Trusted hardware device in a computer 

(57) In a computing platform, a trusted hardware de- 
vice (14) is added to the mothertx>ard (10). The trusted 
hardware device (1 4) is configured to acquire an integ- 
rity metric, for example a hash of the BIOS memory (1 9), 
of the computing platform. The trusted haidware device 
(1 4) is tamper-resistant, difficutt to forge and inaccessi- 
ble to other functions of the platform. The hash can be 
used to convince users that that the operation of the plat- 
form (hardware or software) has not been subverted in 
some way, and is safe to interact with in local or remote 
applications. 

In nrx^re detail, the main processing unit (11 ) o( the 
computing platform is directed to address the trusted 
hardware device (14), in advance of the BIOS memory, 
after release from 'reset*. The trusted hardware device 
(1 4) is configured to receive memory read signals from 
the main processing unit (11) and, in response, return 
instnjctions. in the native language of the main process- 
ing unit (11), that instruct the main processing unit to 
establish the hash and retum the value to be stored by 
the trusted hardware device (14). Since the hash is cal* 
culated in advance of any other system operatuns, this 
is a relatively strong method of verifying the integrity of 
the system. Once the hash has been returned, the final 
instruction calls the BIOS program and the system boot 
procedure continues as normal. 

Whenever a user wishes to interact with the com- 
puting platform, he first requests the integrity metric, 



which he compares with an authentic integrity metric 
that was measured by a trusted party. If the metrics are 
the same, the platform is verified and interactions can 
continue. Otherwise, interaction halts on the basis that 
the operatkxi of the platform may have been subverted. 
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Description 

Technical Field 

[0001] The present invention generally relates to 
trusted devices, trusted computing platforms, trusted 
transactions and methods of operating the same. 

Background Art 

[0002] For commercial applications, a client comput- 
ing platform typically operates in an environment where 
its behaviour is vulnerable to modification by local or re- 
mote entities. This potential insecurity of the platform is 
a limitation on its use by local parties who might other- 
wise be willing to use the platform, or renrtote parties who 
might othenvise communicate with the platform; for ex- 
ample, for the purposes of E-commerce. For the present 
purposes, both local parties and remote parties will be 
referred to as "users' unless othenwise stated. 
[0003] Existing security applications, for example vi- 
rus detect bn software, execute on computing platforms 
under the assumption that the platform will operate as 
intended and that the platform will not subvert processes 
and applications. This is a valid assumption provided 
that the intended software state has not become unsta- 
ble or has not been damaged by other software such as 
viruses. Users, therefore, typically restrict the use of 
such platforms to noncritical applications, and weigh the 
convenience of the using the platforms against the risk 
to sensitive or business critical data. 
[0004] I ncreasing the level of trust in platforms there- 
fore enables greater user confidence in existing security 
applications (such as the 'Secure Sockets Layer* or 
'IPSec') or remote management applcatkxis. This ena- 
bles greater reliance on those applications and hence 
reduced 'cost of ownership'. Greater tnjst also enables 
new electronic methods of busin0ss, since there is 
greater confidence in the correct operation of both kxa\ 
and renrwte computing platforms. 
[0005] In this document, the word trust* is used in the 
sense that something can be trusted' if it always be- 
haves in the way it is expected to behave. 

Disclosure of the Invention 

[0006] The present inventors have appreciated that it 
is desirable to use a physical device in a computing plat- 
form to verify and possibly enforce trust in that platform. 
Typically, the device provides trusted measurement and 
reporting of attributes of the associated platfonm. which 
indk^ate the integrity of the platfonm. Also, most prefer- 
ably, the device is tamper-resistant. 
[0007] In accordance with a first aspect, the present 
inventbn provides computing apparatus comprising 
mounted on an assembly main processing means and 
main memory means, each being connected for com- 
munication with one or more other components on the 



assembly, 

characterised by further comprising a trusted de- 
vice mounted on the assembly and being connected for 
communications with one or nnore other components on 
s the assembly, the trusted device being arranged to ac- 
quire a true value of an Integrity metric of the computing 
apparatus. 

[0008] As used herein for reasons of simplbity of de- 
scriptk)n, the term 'device' also encompasses plural de- 

^0 vices having equivalent function, or equivalent function- 
ality integrated into one or more existing platform devic- 
es or assemblies- Additionally, the term true* as used 
herein implies that the value is that whk:h correctly re- 
flects the state of the computing apparatus. This may 

IS be ensured if the measurement method is substantially 
un-modifiable other than by the trusted device. 
[0009] In accordance with a second aspect, the 
present inventbn provkJes a method of operating a sys- 
tem comprising trusted computing apparatus and a us- 

20 er, the trusted computing apparatus incorporating a 
trusted device being arranged to acquire the true value 
of an integrity metric of the computing apparatus, the 
method comprising the steps of: 
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the tnisted device acquiring the tme value of the in- 
tegrity metrk: of the trusted computing apparatus; 
the user generating a challenge for the trusted com- 
puting apparatus to prove its integrity and submit- 
ting the challenge to the trusted computing appara- 
tus; 

the trusted computing apparatus receiving the chal- 
lenge, and the trusted devk:e generating a re- 
sponse including the integrity metric and retummg 
the response to the user and 
the user receiving the response, extracting the in- 
tegrity metric from the response and comparing the 
integrity metrk: with an authentk^ated metric for the 
trusted computing apparatus that had been gener- 
ated by a trusted party. 



[001 0] In accordance with a third aspect, the present 
invention provides a method of establishing a commu- 
ncatkxis channel in a system between trusted comput- 
ing apparatus and remote computing apparatus, the 

^ method including the step the remote computing ap- 
paratus verifying the integrity of the trusted computrig 
apparatus using the above method, and maintaining the 
communications channel for further transactkxis in the 
event the integrity of the trusted computing apparatus is 

50 successfully verified by the renrnte computing appara- 
tus. 

[0011] In accordance with a fourth embodiment, the 
present invention provktes a method of verifying that 
trusted computing apparatus is trustworthy for use by a 
^ user for processing a partcutar appricatk>n, the method 
including the step of the user verifying the integrity of 
the trusted computing apparatus using the above meth- 
od, and the user using the tnisted computing apparatus 
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to process the particular application in the event the In- 
tegrity of the tnjsted computing apparatus Is success- 
fully verified by the remote computing apparatus. 
[0012] Other aspects and embodiments of the 
present invention will become apparent from the follow- 5 
Ing description and claims. 

Brief Description of the DrawlnQS 

[0013] A preferred embodiment of the present inven- 
tion will now be described by way of example only with 
reference to the accompanying drawings in which: 

Figure 1 is a diagram which shows the motherboard 
of computing apparatus adapted to include a trust- 
ed device according to an embodiment of the 
present invention; 

Figure 2 is a diagram which shows in more detail 
the trusted device shown in Figure 1; 
Figure 3 is a diagram which shows in the contents 
of a certificate stored in the tnjsted device; 
Figure 4 is a diagram, which shows the features of 
a measurement function responsible for acquiring 
an integrity metric; 

Figure 5 is a flow diagram which illustrates the steps 
involved in acquiring an Integrity metric of the com- 
puting apparatus; and 

Figure 6 is a flow diagram which illustrates the steps 
involved in establishing communications between a 
trusted computing platform and a remote platform 
including the trusted platfomn verifying its integrity. 

Best Mode For Carrying Out the Invention. & Industrial 

Applicability 

[001 4] The present exemplary embodiment generally 
provides the incorporation into a computing platform of 
a physical trusted device whose function is to bind the 
identity of the platform to reliably measured data that 
provides an integrity metric of the platform. The identity 
and the integrity metric are compared with expected val- 
ues provided by a trusted party (TP) tfiat is prepared to 
vouch for the trustworthiness d the platform. If there is 
a match, the implication is that at least part of the plat- 
form is operating correctly, depending on the scope of 
the integrty metric. 

[0015] A user verifies the correct operation of the plat- 
form before exchanging other data with the platform. A 
user does this by requesting the trusted device to pro- 
vide its identity and an integrity metric. (Optionally the 
trusted device will refuse to provide evidence of identity 
if it itself was unable to verify correct operation of the 
platform.) The user receives the proof of identity and the 
identity metric, and compares them against values 
which it believes to be true. Those proper values are 
provided by the TP or arK>ther entity that is trusted by 
the user. If data reported t)y the trusted device is the 
same as that provided by the TP. the user trusts the plat- 



form. This is because the usertnists the entity The en- 
tity tmsts the platform because it has previously validat- 
ed the identity and determined the proper integrity met- 
ric of the platform. 

[001 6] Once a user has established trusted operation 
of the platform, he exchanges other data with the plat- 
form. For a local user, the exchange might be by inter- 
acting with some software application oinning on the 
platform. For a remote user, the exchange might involve 
a secure transaction. In either case, the data exchanged 
is 'signed* by the trusted device. The user can then have 
greater confidence that data is being exchanged with a 
platform whose behavbur can be trusted. 
[0017] The trusted device uses cryptographic proc> 
esses but does not necessarily provide an external in> 
terface to those cryptographic processes. Also, a most 
desirable implementation would be to make the trusted 
device tamperproof, to protect secrets by making them 
inaccessible to other platfomi functions and provide an 
environment that is substantially immune to unauthor- 
ised modification. Since tamper-proofing is impossible, 
the best approximatk>n is a trusted device that is tamper- 
resistant, or tamper-detecting. The trusted devce, 
therefore, preferably consists of one physical compo- 
nent that is tamper-resistant. 

[0018] Technk^ues relevant to tamper-resistance are 
well krK>wn to those skilled In the art of security. These 
technk^es include methods for resisting tampering, 
methods for detecting tampering, and methods for elim- 
inating data when tampering is detected. It will be ap- 
preciated that, although tamper-proofing is a most de- 
sirable feature of the present inventkm, it does not enter 
into the normal operation of the invention ai>d, as such, 
is beyond the scope of the present inventk)n and will not 
be described in any detail herein. 
[001 9] The trusted device is preferably a physical one 
because it must be difficutt to forge. It is most preferably 
tamper-resistant because it must be hand to counterfeit. 
It typically has an engine capable of using cryptographic 
processes because it is required to prove identity, both 
locally and at a distance, and it contains at least one 
method of measuring some integrity metric of the plat- 
form with which it is associated. 
[0020] Figure 1 illustrates the nnothertxsard 10 of an 
exemplaiy computer platf omt (not shown). The mother- 
board 10 includes (among other standard components) 
a main processor 11 , main memory 12, a trusted device 
1 4, a data bus 1 6 and respective standard control Ines 
1 7 and address tines 1 8, and BIOS memory 1 9 contain- 
ing the BIOS program for the platform. 
[0021 ] Typically, the BIOS program is kxated in a spe- 
cial reserved memory area, the upper 64K of the first 
megabyte do the system menrK>ry (addresses F000h 
to FFFFh). and the main processor is arranged to \oak 
at this memory tocatkxi first, in accordance with an in- 
dustry wkie standard 

[0022] The signifk:ant difference between the plat- 
form and a oonventkxial platform is that, after reset, the 
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main processor is initially controlled by the trusted de- 
vice, which then hands control over to the platform-spe- 
cific BIOS program, which in turn Initialises all input/out- 
put devices as normal. After the BIOS program has ex- 
ecuted, control is handed over as normal by the BIOS 
program to an operating system program, such as Win- 
dows NT (TM), which is typically loaded into main mem- 
ory 12 from a hard disk drive (not shown). 
[0023] Clearly, this change from the normal procedure 
requires a modification to the implementation of the In- 
dustry standard, whereby the main processor 11 is di- 
rected to address the trusted device 1 4 to receive its first 
instructions. This change may be made simply by hard- 
coding a different address into the main processor 11. 
Attematively, the trusted device 14 may be assigned the 
standard BIOS program address, in which case there is 
no need to modify the main processor configuration. 
[0024] Although, in the preferred embodiment to be 
described, the tnjsted device 14 is a single, discrete 
component, it is envisaged that the functions of the trust- 
ed device 14 may altematively be split into multiple de- 
vices on the mothertxDard, or even integrated into one 
or more of the existing standard devices of the platform. 
For example, it is feasible to integrate one or more of 
the functions of the trusted device into the main proces- 
sor itself, provided that the functions and their commu- 
nications cannot be subverted. This, however, would 
probably require separate leads on the processor for 
sole use by the trusted functions. Addltionaliy or alter- 
natively, although in the present embodiment the trusted 
device is a hardware device that is adapted for integra- 
tion into the mothertoard 1 0. it is anticipated that a trust- 
ed device may be implemented as a 'removable' device, 
such as a dongle, which could be attached to a platform 
when required. Whether the trusted device is integrated 
or removable is a matter of design choice. 
[0025] The trusted device 1 4 comprises a number of 
blocks, as illustrated in Figure 2: a controller 20 for con- 
trolling the overall operation of the trusted device 14, 
and interacting with the other functions on the trusted 
device 14 and with the other devices on the mother- 
board 10; a measurement function 21 for acquiring an 
integrity metric from the platform; a cryptographic func- 
tion 22 for signing or encrypting specified data; and in- 
terface circuitry 23 having appropriate ports (24, 25 & 
26) for connecting the trusted device 14 respectively to 
the data bus 16, control t'mes 17 and address lines 18 
of the motherboard 10. Each of the bkxks in the trusted 
device 14 has access (typically via the controller 20) to 
appropriate volatile memory areas 27 and/or non*vola- 
tile memory areas 28 of the trusted device 14. 
[0026] For reasons of performance, the trusted device 
14 may be implemented as an applicatk)n specific inte- 
grated circuit (ASIC). However, for flexibility, the trusted 
device is preferably an appropriately programmed mi- 
cro-controller. Both ASICs and micro-controllers are 
well known in the art of microelectronics and will not be 
considered herein in any further detail. 



[0027] One item of data stored in the non-voiatite 
memory is a certificate 30, whk:h is illustrated in Figure 
3. The certificate 30 contains at least a public key 32 of 
the trusted device 14 and an authenticated value of a 

5 platform Integrity metric 34 measured by a TP. Optton- 
alty. the trusted device 14 also contains an identity (ID) 
label 36 of the trusted device 14. 
[0028] Where present, the ID label 36 is a conventk>n- 
al ID label, for example a serial number, that is unk:;ue 

10 within some context. The ID label 36 is generally used 
for indexing and labelling of data relevant to the tnjsted 
devk:e 1 4, but is insufficient in itself to prove the identity 
of the platform under trusted conditbns. 
[0029] The trusted device 1 4 is equipped with at least 

IS one method of reliably measuring some Integrity metrk: 
of the computing platform with which it is associated. 
The integrity metrk: is acquired by the measurement 
function 21 , which is illustrated in more detail in Figure 4. 
[0030] The measurement function 21 has access to 

20 non-volatile merrvDry 40 for storing a hash program 41 , 
plus volatile merrwry 42 for storing a computed integrity 
metrki 43, In the form of a digest. The hash program 41 
contains instructions for computing the digest. In code 
that is native to the main processor 11. In additkxi. part 

2S of the measurement functon 21 is configured to respond 
to the main processor 1 1 as if it were addressable mem- 
ory, such as standanj read-only memory, by sensing 
memoiy read signals addressed to the trusted devk^e 
14 and retuming appropriate data. The result is that the 

30 main processor 1 1 sees the tmsted device, for the pur- 
poses of integrity metrk: measurement, as a standard 
read-only memory. 

[0031] In the prefen-ed implementation, as well as the 
digest, the integrity metric includes a Boolean value 44, 

3S which is stored in volatile memory 45 by the measure- 
ment f unctkxi 21 , for reasons that will become apparent. 
[0032] A preferred process for acquiring an Integrity 
metrk; will now be described with reference to Figure 5. 
[0033] In step 500, at switch-on, the measurement 

40 function 21 monitors the activity of the main processor 
11 on the data, control and address lines (16. 17 & 18) 
to determine whether the trusted devce 14 is the first 
memory accessed Under conventkxial operation, a 
main processor wouki first be directed to the BIOS menv 

^ ory first in order to execute the BIOS program. However, 
in accordance with the present embodiment, the main 
processor 11 is directed to the trusted device 1 4, which 
acts as a memory. In step 505, if the tmsted devce 14 
is the first memory accessed, in step 510, the measure- 

so ment functkjn 21 writes to non-volatile memory 45 a 
Boolean value 44, whk:h indicates that the tmsted de- 
vk;e 14 was the first memory accessed. Othenivise, in 
step 515, the measurement functkxi writes a Boolean 
value 44, whk:h indk:ates that the tnjsted device 1 4 was 

55 not the first memory accessed. 

[0034] In the event the trusted devce 1 4 is not the first 
accessed, there is of course a chance that the trusted 
devce 14 will not be accessed at all. This wouki be the 



7 



EP 1 030 237 A1 



8 



case, for example, if the main processor 11 were ma- 
nipulated to run the BIOS program first. Under these cir- 
cumstances, the platform would operate, but would be 
unable to verify its integrity on demand, since the integ- 
rity metric would not be available. Further, if the trusted 
device 14 were accessed after the BIOS program had 
been accessed, the Boolean value 44 would clearly in- 
dicate lack of integrity of the platform. 
[0035] in step 520, when (or if) accessed as a memory 
by the main processor 11 , the main processor 11 reads 
the stored native hash instructions 41 from the meas- 
urement function 21 in step 525. The hash instructions 
41 are passed for processing by the main processor 11 
over the data bus 16. In step 530, main processor 11 
executes the hash instructions 41 and uses them, in 
step 535, to compute a digest of the BIOS memory 19. 
by reading the contents of the BIOS memory 19 and 
processing those contents according to the hash pro- 
gram. In step 540, the main processor 11 writes the conv 
puted digest 43 to the appropriate non-volatile memory 
location 42 in the trusted device 14. The measurement 
function 21 , in step 545, then calls the BIOS program in 
the BIOS memory 19, and execution continues in a con- 
ventional manner. 

[0036] Clearly, there are a number of different ways 
in which the integrity metric may be calculated, depend- 
ing upon the scope of the trust required. The measure- 
ment of the BIOS program's integrity provides a funda- 
mental check on the integrity of a platform's underlying 
processing environment. Other integrity checks could 
involve establishing that various other devices, compo- 
nents or apparatus attached to the platform are present 
and in correct working order. In one example, the BIOS 
programs associated with a SCSI controller coukj be 
verified to ensure communications with peripheral 
equipment could be trusted. In another example, the in- 
tegrity of other devices, for example memory devices or 
co-processors, on the platform coukj be verified by en* 
acting fixed challenge/response interactkxis to ensure 
consistent results. Also, although in the present embod- 
iment the tnjsted device 14 utilises the data bus as its 
main means of communicatnn with other parts of the 
platform, it would be feasible, although not so conven- 
ient, to provide alternative connmunicatksns paths, such 
as hard*wired paths or optical paths. Further, although 
in the present embodiment the trusted device 14 in- 
structs the main processor 11 to calculate the. integrity 
metric, it is anticipated that, in other embodiments, the 
trusted device itself will be arranged to measure one or 
moTQ integrity metrics. 

[0037] Preferably, the BIOS boot process includes 
mechanisms to verify the integrity of the boot process 
itself. Such mechanisms are already known from, for ex- 
ample, Intel's draft 'Wired for Management baseline 
specificatkyi v 2.0 - BOOT Integrity Service*, and in- 
volve calculating digests of software or firmware before 
loading that software or fimnware. Such a computed di- 
gest is compared with a value stored in a certificate pro- 



vided by a trusted entity, whose public key is known to 
the BIOS. The software/firmware is then loaded only if 
the computed value matches the expected value from 
the certificate, and the certificate has been proven valid 
5 by use of the trusted entity's publk: key. Otherwise, an 
appropriate exceptk>n har^iling routine is invoked. 
[0038] Optkxially, after receiving the computed BIOS 
digest, the trusted device 1 4 may inspect the proper val- 
ue of the BIOS digest in the certificate and not pass con- 
trol to the BIOS if the computed digest does not match 
the proper value. AdditK)nally, or alternatively, the trust- 
ed device 1 4 may inspect the Boolean value 44 and not 
pass control back to the BIOS if the trusted device 14 
was not the first memory accessed. 
[0039] Figure 6 illustrates the flow of actk>ns by a TP, 
the trusted device 14 incorporated into a platform, and 
a user (of a rernoXe platform) who wants to verify the 
integrity of the trusted platform. It will be appreciated 
that substantially the same steps as are depicted in Fig- 
ure 6 are involved when the user is a kxal user. In either 
case, the user woukl typically rely on some form of soft- 
ware application to enact the verification. It would be 
possible to mn the software application on the remote 
platform or the trusted platfonn. However, there is a 
chance that, even on the remote platform, the software 
applicatbn could be subverted in some way. Therefore, 
it is anticipated that, for a high level of integrity, the soft- 
ware applcatbn would reskJe on a smart card of the us- 
er, who would insert ttie smart card into an appropriate 
reader for the purposes of verification. 
[0040] At the first instance, a TP, which vouches for 
trusted platforms, will inspect the type of the platform to 
deckle whether to vouch for it or not. This will be a matter 
of policy. If alt is well, in step 600. the TP measures the 
value of integrity metre of the platform. Then, the TP 
generates a certificate, in step 605. for the platform. The 
certificate is generated by the TP by appending the trust- 
ed device's public key, and optionally Its ID label, to the 
measured integrity metric, and signing the string with the 
TPs private key. 

[0041] The trusted device 1 4 can subsequently prove 
its kjentity by using its private key to process some input 
data received from the user and produce output data, 
such that the input/output pair is statistically impossible 
to produce without knowledge of the private key. Hence, 
knowledge of the private key forms the basis of klentity 
in this case. Clearly. It would be feasible to use symmet- 
ric encryption fo form the basis of identity. However, the 
disadvantage of using symmetric encryption is that the 
user woukf need to share his secret with the trusted de- 
vice. Further, as a result of the need to share the secret 
with the user, while synrtmetric encryption woukl in prin- 
ciple be sufficient to prove identity to the user, it woukJ 
insufficient to prove identity to a third party, who coukl 
not be entirely sure the verification originated from the 
trusted device or the user. 

|0042) In step 610, the tmsted device 14 is initialised 
by writing the certificate 30 into the appropriate non-vol- 
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atile memory locations of the trusted device 14. This is 
done, preferably, by secure communicatton with the 
trusted device 14 after it is installed in the motherboard 
10. The method of writing the certificate to the trusted 
device 14 is analogous to the method used to initialise 
smart cards by writing private keys thereto. The secure 
communications is supported by a 'master key', known 
only to the TP, that is written to the trusted device (or 
smart card) during manufacture, and used to enable the 
writing of data to the trusted device 14; writing of data 
to the trusted device 1 4 without knowledge of the master 
key is not possible. 

[0043] At some later point during operation of the plat- 
form, for example when it is switched on or reset, in step 
615, the trusted device 14 acquires and stores the in- 
tegrity metric 42 of the platform. 
[0044] When a user wishes to communk:ate with the 
platform, in step 620. he creates a nonce, such as a ran- 
dom number, and. in step 625. challenges the trusted 
device 14 {the operating system of the platform, or an 
appropriate software application, is arranged to recog- 
nise the challenge and pass it to the tmsted device 14, 
typically via a BIOS-type call, in an appropriate fashion). 
The nonce is used to protect the user from deception 
caused by replay of oM but genuine signatures (called 
a 'replay attack') by untaistworthy platforms. The proc- 
ess of providing a nonce and verifying the response is 
an example of the well-known 'challenge/response' 
process. 

[0045] In step 630, the trusted devKe 1 4 receives the 
challenge and creates a digest of the measured integrity 
metric and the nonce, and optwnally its ID label. Then, 
in step 635. the trusted devk;e 14 signs the digest, using 
its private key, and returns the signed digest, accompa- 
nied by the certificate 30. to the user. 
[0046] I n step 640. the user receives the challenge re- 
sponse and verifies the certifrcate using the welt known 
public key of the TP. The user then, in step 650, extracts 
the trusted device's 14 public key from the certificate 
and uses it to decrypt the signed digest from the chal- 
lenge response. Then, in step 660. the user verifies the 
nonce inskje the challenge response. Next, in step 670. 
the user compares the computed integrity metric, whk:h 
it extracts from the challenge response, with the proper 
platform integrity metric, which it extracts from the cer- 
tificate. If any of the foregoing verification steps fails, in 
steps 645, 655, 665 or 675, the whole process ends in 
step 680 with no further communications taking place. 
[0047] Assuming all is well, in steps 665 and 690. the 
user and the trusted platform use other protocols to set 
up secure communk^tbns for other data, where the da- 
ta from the platform is preferably signed by the trusted 
device 14. 

[0048] The techniques of signing, using certificates, 
and challenge/response, and using them to prove iden- 
tity, are well known to those skilled in the art of security 
and will, thus, not be described in any moredetail herein. 



Claims 

1. Computing apparatus comprising mounted on an 
assembly main processing means and main mem- 
s cry means, each being connected for communica- 
tion with one or more other components on the as- 
sembly, 

characterised by further comprising a tnjsted 
device mounted on the assembly and being oon- 
10 nected for communicatkxis with one or more other 
components on the assembly, the trusted device 
being arranged to acquire a true value of an integrity 
metric of the computing apparatus. 

IS 2. Computing apparatus according to claim 1 . wherein 
the trusted device comprises device memory 
means and means for instructing the main process- 
ing means to determine the integrity metric arid re- 
turn the integrity metric for storage in the device 

20 memory means. 

3. Computing apparatus according to claim 2. wherein 
the means for instructing the main processing 
means comprises, stored in the devce memory 
2S means, program code native to the main processing 
means, and the tmsted device is arranged to trans- 
fer the instructions of the program code to the main 
processing means. 

30 4. Computing apparatus according to claim 3, wherein 
the platform is arranged to cause the instructions to 
be the first instructions executed after release from 
reset. 

3S 5. Computing apparatus according to claim 3 or claim 
4, wherein the tmsted device is arranged to transfer 
the instructions to the main processing means in re- 
sponse to memory read signals from the main 
processing means. 

40 

6. Computing apparatus according to any one of 
claims 1 to 5. wherein the trusted device comprises 
device memory means and is arranged to rrxxiitor 
the data bus means and store in the device memory 
45 means a flag in the event the first memory read sig- 
nals generated by the main processing means after 
the computing apparatus is released from reset are 
addressed to the tmsted device. 

so 7. Computing apparatus according to any one of 
claims 1 to 6. wherein the tmsted device has stored 
'm device memory means at least one of: 

a unique identity of the trusted device; 
ss an authenticated integrity metric generated by 

a tmsted party; and 
a secret. 
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a Computing apparatus according to claim 7. wherein 
the trusted device has stored in device memory 
means a secret comprising a private asymmetric 
encryption key. 

9. Computing apparatus according to claim 8. wherein 
the trusted device also has stored in device memory 
means a respective public encryption key that has 
been signed by a trusted party. 

1 0. Computing apparatus according to claim 8 or claim 
9. wherein the trusted device has stored in device 
memory means an authenticated integrity metric 
generated by a trusted party and includes a encryp- 
tion function, the trusted device being arranged to 
generate a response to a received challenge, the 
response comprising an acquired integrity metric 
and the authentk:ated integrity metric, both signed 
by the encryption function using the private asym- 
metric encryptkxi key. 

11 . A trusted device configured for use in computing ap- 
paratus according to any one of the preceding 
claims. 

1 2. A method of operating a system comprising trusted 
computing apparatus and a user, the trusted com- 
puting apparatus incorporating a trusted devk:e be- 
ing arranged to acquire the tnje value of an integrity 
metric of the computing apparatus, the method 
comprising the steps of: 

the trusted device acquiring the true value of 
the integrity metre of the trusted computing ap- 
paratus; 

the user generating a challenge for the trusted 
computing apparatus to prove its integrity and 
submitting the challenge to the trusted comput* 
ing apparatus; 

the trusted computing apparatus receiving the 
challenge, and the trusted device generating a 
response including the integrity metric and re- 
turning the respor^ to the user; and 
the user receiving the response, extracting the 
integrity metric from the response and compar- 
ing the integrity metric with an authenticated 
metric for the tnisted computing apparatus that 
had t>een generated by a trusted party. 

13. A method according to claim 12, wherein the chal- 
lenge includes a nonce, the response includes the 
integrity metric and the norKe, both digitally signed 
by the tojsted device using a encryptkxi algorithm, 
and the user verifies the integrity metric and the 
nonce using a respective encryptkxi algorithra 

1 4. A method according to claim 1 3, wherein the trusted 
device uses a private encryptkyi key to sign the in- 



tegrity metre and the nonce, and the user uses the 
respective public encryptkxi key to verify the integ- 
rity metric and the nonce. 

s 15. A method according to claim 14, wherein the re- 
sponse includes a certificate held by the tmsted de- 
vice, which certificate has been digitally signed by 
a trusted party using a private encryptbn key of the 
trusted party, the certificate including the public en- 

10 cryption key of the tnjsted device, and the user ver- 
ifies the certificate using the public encryption key 
of the trusted party and uses the public encryptkxi 
key from the certlfk:ate to verify the integrity metric 
and the nonce. 

IS 

16. A method of establishing a communicatbns chan- 
nel in a system between trusted computing appara- 
tus and remote computing apparatus, the method 
including the step of the remote computing appara- 

20 tus verifying the integrity of the trusted computing 
apparatus using the method according to any one 
of claims 12 to 15, and maintaining the communi- 
cations channel for further transactions in the event 
the integrity of the tnjsted computing apparatus is 

2S successfully verified by the remote computing ap- 
paratus. 

17. A method of verifying that trusted computing appa- 
ratus is trustworthy for use by a user for processing 

30 a partcular applicatkxi, the method including the 
step of the user verifying the integrity of the trusted 
computing apparatus using the method according 
to any one of claims 12 to 15, and the user using 
the trusted computing apparatus to process the par- 

35 ticular applicatkxi in the event the integrity of the 
trusted computing apparatus is successfully veri- 
fied by the remote computing apparatus. 

1 a Trusted computing apparatus adapted for use in ac- 
^ cordance with the method dt any one of claims 12 
to 17 

19. Remote computing apparatus arranged for use in 
accordance with claum 16. 

45 

20. A trusted devee arranged for use in accordance 
with any one of claims 12 to 17. 

21 . Computing apparatus configured to receive a trust- 
so^ ed device as claimed in claim 1 1 . 
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